Fixes #144.

What's going on

StreamState::insert in crates/malachite-app/src/streaming.rs works out how many parts a stream should have from the Fin message's sequence:

self.expected_messages = msg.sequence as usize + 1;

The comment above it says the + 1 can't overflow because of MAX_MESSAGES_PER_STREAM, but expected_messages is taken from the Fin sequence, which is a wire field the sending peer controls, not from the message cap. A single gossiped Fin at sequence = u64::MAX reaches that line unchecked (received_proposal_part.rs:163 hands the raw message straight to streams_map.insert), and u64::MAX as usize + 1 overflows: a panic in debug or debug-assertions builds, and in release it wraps instead, so the stream can never complete and just sits on a per-peer slot until the 60s age sweep clears it.

Fix

A complete stream holds fin.sequence + 1 messages and can never hold more than MAX_MESSAGES_PER_STREAM, so a Fin with sequence >= MAX_MESSAGES_PER_STREAM is describing a stream that can never complete. I reject and evict it up front, the same way the other malformed-stream paths already do (new StreamInsertResult::FinSequenceOutOfRange), which also takes the overflow off the table. The misleading comment is corrected while I'm there.

Testing

Added test_fin_with_out_of_range_sequence_is_rejected_without_overflow, covering the u64::MAX case and the MAX_MESSAGES_PER_STREAM boundary. Both now return Pending with no stream left tracked, instead of panicking. The rest of the streaming suite stays green:

cargo test -p arc-node-consensus --lib streaming::
test result: ok. 47 passed; 0 failed; 0 ignored

cargo clippy -p arc-node-consensus --lib is clean too.